Add OSV-scanner PR gate + Dependabot remediation SLA, fix stale frontend lockfile - #671

Summary

close #646

No PR-time dependency vulnerability gate exists today — security-audit.yml (npm audit / cargo audit) and sbom-scan.yml (Grype) both only run on a weekly schedule. Meanwhile frontend/package-lock.json had drifted from frontend/package.json badly enough that npm ci was already broken on main (see commit 1). This PR:

1. Fixes the lockfile drift.
2. Adds an OSV-Scanner job that runs on every PR and fails on High/Critical findings across every real lockfile in the repo.
3. Adds/refreshes .github/dependabot.yml with grouped PRs per ecosystem and a documented remediation SLA.
4. Documents the triage process in docs/vulnerability-management.md.

Commit 1 — fix(frontend): resolve stale package-lock.json drift

Files changed: frontend/package.json (+2/-2 lines), frontend/package-lock.json (regenerated, 4245 insertions / 4085 deletions)

Two concrete bugs, not just staleness:

• frontend/package.json line 24: "@finchippay/sdk": "*" had no matching entry anywhere in package-lock.json — npm was silently not locking it at all, so OSV-Scanner/Dependabot couldn't see it against the advisory database. Changed to "@finchippay/sdk": "file:../sdk" (its real path in this monorepo) so it resolves and appears in the lockfile.
• frontend/package.json line 83: "postcss": "^8" as a direct devDependency, while package.json#overrides separately pinned postcss to 8.5.26. npm forbids overriding a direct dependency this way (EOVERRIDE) — this was already breaking npm ci on main, verified locally: npm error Override for postcss@^8 conflicts with direct dependency. Fixed by pinning the direct dependency to 8.5.26 to match the override's intent.
• frontend/package-lock.json regenerated in full from the corrected package.json (lockfileVersion 3, 1204 resolved packages).

Verified: confirmed npm ci fails on the original files with the exact EOVERRIDE error above; confirmed the regenerated lockfile installs cleanly for the @finchippay/sdk and postcss entries specifically. Backend's backend/pnpm-lock.yaml was checked too — pnpm install --frozen-lockfile passes clean, no drift there, no changes needed.

Known follow-up (not fixed here, out of scope): regenerating the lockfile surfaced a real peer-dependency conflict — next@^16.3.0 vs. @storybook/experimental-nextjs-vite@8.6.18's peer range (^14.1.0 || ^15.0.0). This doesn't block the OSV-Scanner gate (it reads the lockfile directly, no install needed), but a plain npm ci in frontend/ needs --legacy-peer-deps until Storybook's Next.js addon is upgraded or Next is pinned back — this is a version-compatibility decision outside this issue's scope, tracked in docs/vulnerability-management.md and should be filed as a separate follow-up issue.

Cargo.lock was not regenerated — no cargo/rustup toolchain was available to verify it in this environment, and the issue only calls out frontend/package-lock.json for drift resolution. It's included in the new OSV-Scanner job's scan list regardless.

Commit 2 — ci(security): add OSV-Scanner PR gate and Dependabot config

.github/workflows/osv-scanner.yml (new, 88 lines)

• Triggers on pull_request (→ main), push (→ main), and workflow_dispatch — this is the new PR-time gate; every other security workflow in the repo (security-audit.yml, sbom-scan.yml) only runs on a weekly schedule.
• Installs OSV-Scanner pinned to v2.5.0 (a tagged release, not latest) via the official binary download URL.
• Scans every real lockfile found in the repo: package-lock.json, frontend/package-lock.json, backend/package-lock.json, backend/pnpm-lock.yaml, Cargo.lock — covering npm, pnpm, and Cargo against the OSV/GHSA database, the same source Dependabot uses.
• Fails the job (exit 1) if any vulnerability group's max_severity (CVSS base score) is >= 7.0 (High or Critical). Findings below that threshold are logged but don't fail the build, matching the acceptance criteria ("fails on high/critical").
• Uploads full JSON results as a build artifact (osv-scan-results) so low/medium findings and full advisory detail are still reviewable.

.github/dependabot.yml (new, 77 lines)

• npm ecosystem entries for / (root workspace), /frontend, /backend (covers both package-lock.json and pnpm-lock.yaml), and /sdk.
• cargo ecosystem entry for / (workspace root, matches Cargo.toml).
• github-actions ecosystem entry for / (keeps the CI supply chain itself patched).
• All weekly (Monday), each with a groups: block bundling minor/patch updates into a single PR per ecosystem/directory to cut review noise; major bumps for the root workspace are excluded from auto-updates and left for manual review.
• Labeled dependencies + ecosystem + security for easy triage/filtering.

docs/vulnerability-management.md (new, 84 lines)

• Documents the two detection layers (OSV-Scanner PR gate, Dependabot) and how they relate to the existing weekly npm audit/cargo audit/Grype workflows.
• Remediation SLA, mirroring the response targets already committed to in SECURITY.md:
  Severity | Acknowledge | Remediate by -- | -- | -- Critical | 24 hours | 7 days High | 48 hours | 14 days Medium | 1 week | 30 days Low | 2 weeks | Best effort
• Step-by-step triage process (identify → confirm reachability → prefer upgrade → mitigate if no fix → dismiss false positives with a reason → verify).
• Notes the grouped-PR strategy and the known Storybook/Next peer-dependency follow-up.

Acceptance criteria checklist

• CI fails on High/Critical findings from OSV-Scanner across all lockfiles (.github/workflows/osv-scanner.yml, runs on every PR)
• dependabot.yml defines grouped PRs and a documented SLA (grouping in the config itself; SLA table in docs/vulnerability-management.md, referenced from the config's header comment)
• Stale lockfile drift resolved — frontend/package-lock.json now matches frontend/package.json (verified: no more EOVERRIDE, @finchippay/sdk now resolves)
• Triage process documented (docs/vulnerability-management.md)